fix (fileprovider): Consume lock ETags before File Provider content updates - #10641

Issue

Opening a Microsoft Word document creates a local Word lock file, which causes the File Provider extension to send a WebDAV LOCK request.

The server lock succeeded, but locking also changed the server ETag. The File Provider previously used that ETag for both:

• metadataVersion
• contentVersion

A lock-only ETag change therefore appeared to macOS as changed file contents. File Provider attempted to evict or replace the materialized document while Word still had it open, resulting in Resource busy, FP -2008, and a Finder cloud/error icon.

A second case occurred when the document was already locked by the same client. The LOCK response restored the local token but returned the existing ETag. Because the ETag did not change, macOS did not refresh its cached item metadata. The document remained advertised as non-writable and macOS applied the immutable uchg flag.

Fix

The implementation separates server metadata changes from actual file-content changes:

1. The ETag and token returned by LOCK are written directly to the target item's metadata.

2. A persisted fileProviderContentVersion retains the version of the file contents already known to File Provider. A lock-only ETag transition changes metadataVersion while leaving contentVersion unchanged. A successful upload advances both to the upload ETag.

3. After storing the lock token, the target item's synchronization timestamp is updated and the existing working-set change notifier is triggered. This immediately reports the updated lock capabilities to macOS.

4. The effective lock-ownership state is included in metadataVersion. Recovering a local token therefore refreshes the item even when LOCK returns the same ETag.

5. Both capabilities and fileSystemFlags recognize a locally owned token lock as writable. This prevents macOS from applying the immutable uchg flag.

A separate File Provider content version is required. Simply updating the ETag would also change contentVersion, causing macOS to treat the lock-only transition as changed file contents and attempt another replacement.

Dependent on nextcloud/NextcloudKit#249

Assisted-by: Codex:GPT-5